Many software applications include large quantities of resource strings, such as menu labels, feature descriptions, and other character strings that may be displayed in a user-interface to an application. A resource file or files is typically used to store the resource strings for an application or suite of applications. The resource file may be accessed at runtime by other components of the application when a particular string or set of strings is needed for display in a user interface to the application.
Compression and encoding technology may be employed during the build process to reduce the size of a resource file. A reduced file size is advantageous in view of bandwidth and storage constraints that may be encountered when provisioning and delivering an application. For example, a reduced file size may make downloading an application package faster than it otherwise would be. In addition, the reduced file size may require less local storage space once it has been downloaded to a local environment. Compression may be especially beneficial with respect to applications that provide support for language localization as a given menu label or other such user interface item may be described by multiple character strings, each in a different language.
While a variety of compression technologies exist for compressing text files, many are not well suited to compressing relatively short text strings, such as a resource string, because they usually do not exhibit a repetitive pattern. In addition, most compression technologies compress an entire file and then, during decompression, decompress the entire file at once. In contrast, resource strings are decompressed on a per-string basis when a string is needed, as opposed to decompressing an entire source file at that time.
Decompressing resource strings on a per-string basis mandates that a particular resource string be located quickly in a resource file. How strings are named can impact the speed with which they are found. Giving resource strings numerical identifiers in an index allows for fast look-up at runtime, but such identifiers are difficult to maintain over time, especially across multiple development and build platforms. Utilizing resource names may increase ease of use and maintainability, but results in slow look-up times at runtime.
A balance is therefore continuously sought between the storage gains achieved by resource string compression and encoding, and the performance load presented by decompression, decoding, and various naming constructs at runtime.